Subject: New value 'recycle' for appn*AdminState objects

From: "R.E. (Robert) Moore (254-4436)" <[email-masked]>
Date: Fri, 20 Sep 96 09:25:28 EDT

In the course of implementing the appnPortAdminState and appnLsAdminState
objects, we've discovered that they provide less function than the
corresponding managed objects in our CMIP implementation.  Specifically,
they don't support the capability for a Management Station to recycle
(i.e., deactivate and then immediately reactivate) the port or link
station through which it is communicating with the agent.  Since
"recycle" is really a command rather than a state, we'd need to
reinterpret the objects a bit to introduce it.  With this in mind, as
well as Randy's request that we clarify the descriptions for these
objects, I'd like to propose the following:

appnPortCommand OBJECT-TYPE
      SYNTAX INTEGER {
                      deactivate(1),
                      activate(2),
                      recycle(3),
                      ready(4)
                     }
      MAX-ACCESS read-write
      STATUS current
      DESCRIPTION
          "Object by which a Management Station can activate, deactivate,
          or recycle (i.e., cause to be deactivated and then immediately
          reactivated) a port, by setting the value to activate(1),
          deactivate(2), or recycle(3), respectively.  The value ready(4)
          has no meaning on a set operation; it is returned in response
          to a get operation if no set operation has been directed to
          this object."

      ::= { appnPortEntry 2 }

appnLsCommand OBJECT-TYPE
      SYNTAX INTEGER {
                      deactivate(1),
                      activate(2),
                      recycle(3),
                      ready(4)
                     }
      MAX-ACCESS read-write
      STATUS current
      DESCRIPTION
          "Object by which a Management Station can activate, deactivate,
          or recycle (i.e., cause to be deactivated and then immediately
          reactivated) a link station, by setting the value to
          activate(1), deactivate(2), or recycle(3), respectively.  The
          value ready(4) has no meaning on a set operation; it is
          returned in response to a get operation if no set operation has
          been directed to this object."

      ::= { appnLsEntry 2 }

An agent that's unable to support recycling of a port or link station
could always indicate this fact via its AGENT-CAPABILITIES.

What is the group's opinion on making this change to the MIB?

Bob Moore, IBM Network Management Architecture

---

From: Bob Clouston <[email-masked]>
Date: Wed, 16 Oct 1996 15:47:01 -0400 (EDT)

Sorry I'm a little slow responding to this...
What action would an agent perform for a recycle if the port or link
is in a state other than active?  I'd like to see this explicitly
stated for inactive and pending states.

Also, you could argue this function does exist today in this mib, 
by issuing deactivate, querying the state until inactive, then
issuing an activate.  Given that most agents will require base code
api changes to support recycle since usually the deactivate command
will return before the link actually deactivated, a management 
application would probably need to support this method anyway.
If you are prepared to have a manager and an agent support this,
I'll agree to it but I want to make sure someone really thinks
this is implementable.  I know the CMIP manager application has a
recycle command at the user interface but does it really result in 
a recycle flow, or an inact/act?

Bob Clouston